Seeing this all laid out, I am wondering:

• Do we still like the Store_SpliceDynamicData name since splice events are now ~guaranteed to operate on one field at a time and it includes both information for splicing within the field and for all of the dynamic data? Wondering if this should be something like Store_SpliceDynamicField to clarify the intent.
• With above, I am also wondering if it's worth clarifying some argument names like startWithinField to fieldStart and start -> dynamicDataStart.
• "dynamic" in dynamicFieldIndex might be redundant since this is a Store_SpliceDynamicData event. Also worth clarifying if this is the field index in the list of fields for the whole schema or field index among dynamic fields (I think it's the former?)

Do we need startWithinField? Couldn't that be computed from dynamicFieldIndex, start and encodedLengths? I'd prefer adding that one additional field to the event than refactoring the event name and other field names. The current naming feels very intuitive if you're thinking of the data as one byte blob, while the Store_SpliceDynamicField naming would be a little more intuitive if you're storing data in separate locations, but I don't there is a strong enough bias in either direction to change the name at this point.

const fieldLengths = getFieldLengths(encodedLengths); // some sort of decoding function
const fieldStart = fieldLengths.slice(0, dynamicFieldIndex).reduce((sum, length) => sum + length, 0);
const startWithinField = start - fieldStart;

checks out ✅